Software systems commonly support visual editing environments where users can manipulate data or visual abstractions of data to create design models, graphics and/or text-based documents that are stored in electronic files. The electronic files contain data structures that store information created and manipulated in a visual editing environment. For example, some electronic files store complex design models that are created using a Unified Modeling Language (UML), such as those used to enable the computer-based design of integrated circuits, mechanical drawings, and even the functional modeling of computer code using block diagrams and the like. Other electronic files store text-based files created using word processing software. Complex text-based files store information in a structured format so that attributes applied to the text (e.g. italics, underlining, fonts, footnotes, etc.) can be accurately recreated when the file is opened and viewed by users, exported or printed.
After a period of development or editing the information stored in the data structures may be so complex that it is difficult to understand by simple visual inspection. For example, a user, reviewing the information for the first time, may be unable to identify the portions of information that are most relevant for their current purpose, or may be overwhelmed by the details and subsequently overlook information relevant to their current purpose. Additionally, reviewing only the information stored in the data structure, as reproduced in a suitable visual editing environment, may not necessarily reveal the rationale behind design choices that have shaped the information stored in the data structure as it currently exists. Some of these issues may be more pertinent for design models created using CAD (Computer Automated Design) tools (e.g. to represent circuit diagrams, functional blocks and mechanical drawings, etc.) than for text-based files created using word processing software. However, in both instances it may be useful to review the development history of the information represented to attempt to understand the meaning of the information represented.
Prior attempts to store the development history include “drilling down”, version control management, recording annotations, and maintaining persistent “undo” stacks. The concept of drilling down (or “opening down”) is typically related to viewing design models created using CAD tools. At a high level of abstraction a design model is schematically represented by an interconnected combination of functional blocks or schematically represented components. Each functional block is an abstraction of a system, process, apparatus or component feature, and each functional block has one or more electronic files storing requisite information defining the particular functional block. Drilling down is the process of selecting and viewing the details of a functional block within the visual editing environment in order to review the underlying information in a functional block. Despite breaking visually abstracted information into more manageable, and possibly reusable, modules this method of organizing and storing information does not inherently provide any way to track the actual development history of a high level design and the design choices that shaped the design into its current state.
As an alternative, version control management is another option used in the prior art. Version control management systems or processes are typically implemented such that multiple versions of a design model or text-based file are stored, where each version is a copy of the design model or text-based file as it existed at some prior point in the development. Version control management systems or processes are clumsy and difficult to use and maintain. A user must explicitly load earlier versions and run “compare-merge” operations to reveal and track changes between versions. Moreover, the number of details that are changed between versions (i.e. “the delta”) tends to be large and unpredictable since users are in control of creating new versions. And users typically only create new versions after doing extensive amounts of work.
Another alternative that has been combined with drilling down and version control management is recording annotations. Annotations are comments or notes added by a developer/writer during the course of development or writing/editing. However, since annotations are typically left to a user to add, annotations are not always and/or consistently added and stored. Consequently, the use of annotations is often ad hoc and sparse. An alternative, is to incorporate a rationale tracking tool to explicitly document all design decisions. However, such tools are cumbersome and slow down the development process, and thus, are not widely employed.
Lastly, is the use of persistent undo stacks. In a typical software tool (e.g. word processor or CAD tool) a stack of “undoable” commands (i.e. commands that can be reversed) is stored while the information in an electronic file is being edited in the visual editing environment. Most software tools delete the stack when a user closes the visual editing environment or saves the current state of the electronic file as a version. However, some tools have implemented a persistent undo stack in which the information in the stack of undoable commands is stored within the data structure of the electronic file. There are several drawbacks related to using a persistent undo stack for reviewing the development history of information stored in an electronic file. First, undoing the changes inherently undoes the work done to date and a “redo” function must be used to restore the information to the state it was in when the user opened the file. This is a cumbersome way of trying to track the development of the information stored in an electronic file. Second, if a user undoes changes and then starts editing the information, as it existed in a previous state, all of the subsequent undo/redo states are lost. Consequently, the information cannot be restored to the state it was in when the electronic file was opened, unless the user remembers exactly the state of the information and is capable of reproducing the work. Third, the granularity of the undo stack is very fine. It includes all undoable commands irrespective of the actual importance of each command to the development of the information stored in an electronic file. Simply reversing all changes to get to a previous point in the development of the information typically results in confusion and, as already noted, any edits at a prior interim position would introduce errors and/or effectively destroy the quality of the information created to date.